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ABSTRACT: 

The explosion of capabilities and new products within 
the sphere of Information Technology (IT) has fostered 
widespread, overly optimistic opinions regarding the indus- 
try, based on common but unjustified assumptions of qual- 
ity and correctness of software. These assumptions are en- 
couraged by software producers and vendors, who at this 
late date have not succeeded in finding a way to overcome 
the lack of an automated, mathematically sound way to de- 
velop correct systems from requirements. NASA faces this 
dilemma as it envisages advanced mission concepts that in- 
volve large swarms of small spacecraft that will engage co- 
operatively to achieve science goals. Such missions entail 
levels of complexity that beg for new methods for system 
development far beyond today’s methods, which are inad- 
equate for ensuring correct behavior of large numbers of 
interacting intelligent mission elements. New system de- 
velopment techniques recently devised through NASA-led 
research will offer some innovative approaches to achieving 
correctness in complex system development, including au- 
tonomous swarm missions that exhibit emergent behavior, 
as well as general software products created by the comput- 
ing industry. 

I. Introduction 

Software has become pervasive. We encounter it in 
our everyday fives: the average electric razor contains the 
equivalent of more than 100,000 fines of code, several high- 


end cars contain more software than the onboard systems of 
the Space Shuttle. We are reliant on software for our trans- 
portation and entertainment, to wash our clothes and cook 
our meals, and to keep us in touch with the outside world 
via the Internet and our mobile phones. 

The Information Technology industry, driven by software 
development, has made remarkable advances. In just over 
half a century, it has developed into a trillion-dollar-per- 
year industry, continually breaking its own records [18], 
[28], 

Some breathtaking statistics have been reported for the 
hardware and software industries [17], [46]: 

• The Price-to-Performance ratio doubles every 18 
months, resulting in a 100-fold increase in perfor- 
mance every decade. 

• Performance progress in the next 18 months will 
equal all progress made to date. 

• New storage available equals the sum of all previ- 
ously available storage ever. 

• New processing capability equals the sum of all pre- 
vious processing power. 

Simultaneously, a number of flawed assumptions have 
arisen regarding the way we build both software and hard- 
ware systems [38], [46], which include: 

• Human beings can achieve perfection; they can avoid 
makin g mistakes during installation, maintenance 
and upgrades. 

• Software will eventually be bug-free; the focus of 
companies has been to hire better programmers, and 
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Fig. 1 . Contrasting availability of Telephone Systems, Computer Systems, 

Internet, and Mobile Phones. 

the focus of universities is to better train software en- 
gineers in development lifecycle models. 

• Mean-time between failure (MTBF) is already very 
large (approximately 100 years) and will continue to 
increase. 

• Maintenance costs are a function of the purchase 
price of hardware; and, as such, decreasing hard- 
ware costs (price/performance) results in decreases 
in maintenance costs. 

II. Software Problems 

With the situation stated this way, many flawed assump- 
tions regarding the IT industry come into view. The situa- 
tion is even worse if we focus primarily on software. The 
Computing industry has failed to avoid software-related 
catastrophes. Notable examples include: 

• Therac-25, where cancer patients were given lethal 
doses of radiation during radiation therapy [33]. 

• Ariane 5, where it was assumed that the same launch 
software used in the prior version (Ariane 4) could be 
reused. The result was the loss of the rocket within 
seconds of launch [34]. 

• The Mars Polar Lander, where failure to initialize 
a variable resulted in the craft crash landing on the 
Martian surface, instead of reverse thrusting and 
landing softly [1], 

Progress in software regularly lags behind hardware. In 
the last decade, for example, two highly software-intensive 
applications, namely Internet communications and mobile 
phone technology, have suffered reduced availability and 
increased down time , while their hardware counterparts, 
computer hardware and telephony systems, have continued 
to improve. Figure 1 illustrates this trend [18]. 

A. An Historic Problem 

The realization that software development has lagged 
greatly behind hardware is hardly a new one [7], nor is the 
realization that our software development processes have 
some severe deficiencies. 

Brooks, in a widely quoted and much-referenced arti- 
cle [8], warns of complacency in software development. He 


stresses that, unlike hardware development, we cannot ex- 
pect to achieve great advances in productivity in software 
development unless we concentrate on more appropriate 
development methods. He highlights how software sys- 
tems can suddenly turn from being well-behaved to behav- 
ing erratically and uncontrollably, with unanticipated de- 
lays and increased costs. Brooks sees software systems as 
“werewolves” and rightly points out that there is no single 
technique, no Silver Bullet, capable of slaying such mon- 
sters [7]. 

On the contrary, more and more complex systems are run 
on highly distributed, heterogeneous networks, subject to 
strict performance, fault tolerance, and security constraints, 
all of which may conflict. Many engineering disciplines 
must contribute to the development of complex systems in 
an attempt to satisfy all of these requirements. No single 
technique is adequate to address all issues of complex sys- 
tem development; rather, different techniques must be ap- 
plied at different stages of development (and throughout the 
development process) to ensure unambiguous requirements 
statements, precise specifications that are amenable to anal- 
ysis and evaluation, implementations that satisfy the re- 
quirements and various (often conflicting) goals, re-use, re- 
engineering and reverse engineering of legacy code, appro- 
priate integration with existing systems, ease-of-use, pre- 
dictability, dependability, maintainability, fault tolerance, 
etc. [7]. 

Brooks [8] differentiates between the essence (that is, 
problems that are necessarily inherent in the nature of soft- 
ware) and accidents (that is, problems that are secondary 
and caused by current development environments and tech- 
niques). He points out the great need for appropriate means 
of coming to grips with the conceptual difficulties of soft- 
ware development — that is, for appropriate emphasis on 
specification and design, rather than on coding and testing. 

In his article [8], he highlights some successes that have 
been achieved in gaining improvements in productivity, but 
points out that these address problems in the current devel- 
opment process, rather than the problems inherent in soft- 
ware itself. In this category, he includes: the advent of 
high-level programming languages, time-sharing, and uni- 
fied programming environments. Object-oriented program- 
ming, techniques from artificial intelligence, expert sys- 
tems, automatic programming, program verification, and 
the advent of workstations, he sees as non-bullets, as they 
will not help in slaying the werewolf. 

He sees software reuse, rapid prototyping, incremental 
development, and the employment of top-class designers as 
potential starting points for the Silver Bullet, but warns that 
none in itself is sufficient. 

Brooks’ article has been very influential, and remains 
one of the classics of software engineering. His viewpoint 
has been criticized, however, as being overly pessimistic 
and for failing to acknowledge some promising develop- 
ments [7]. 
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Harel, in an equally influential paper, written as a rebuttal 
to Brooks [20], points to developments in Computer-Aided 
Software Engineering (CASE) and visual formalisms [19] 
as potential bullets. Harel’s view is far more optimistic. He 
writes five years after Brooks, and has seen the develop- 
ments in that period. The last forty years of system de- 
velopment have been equally difficult, according to Harel, 
and, using a conceptual vanilla framework, the develop- 
ment community has devised means of overcoming many 
difficulties. As we address more complex systems, Harel 
argues that we must devise similar frameworks that are ap- 
plicable to the classes of system we are developing. 

Harel, along with many others, including the authors of 
this paper, believes that appropriate techniques for model- 
ing must have a rigorous mathematical semantics, and ap- 
propriate means for representing constructs. This differs 
greatly from Brooks, who sees representational issues as 
mainly accidental. 

III. New Challenges for Software Engineering 

Clearly there have been significant advances in software 
engineering tools, techniques, and methods, since the time 
of Brooks’ and Harel’s papers. 

In many cases, however, the advantages of these devel- 
opments have been mitigated by corresponding increases 
in demand for greater, more complex functionality, stricter 
constraints on performance and reaction times, and at- 
tempts to increase productivity and reduce costs, while si- 
multaneously pushing systems requirements to their lim- 
its. NASA, for example, continues to build more and more 
complex systems, with impressive functionality, and in- 
creasingly autonomous behavior. In the main, this is es- 
sential. NASA missions are pursuing scientific discovery 
in ways that require autonomous systems. While manned 
exploration missions are clearly in NASA’s future (such as 
the Exploration Initiative’s plans to return to the moon and 
put Man on Mars), several current and future NASA mis- 
sions, for reasons that we will explain below, necessitate 
autonomous behavior by unmanned spacecraft. 

We will describe some of the challenges for software en- 
gineering emerging from new classes of complex systems 
being developed by NASA and others. We will discuss 
these in Section Hl-A with reference to a NASA concept 
mission that is exemplary of many of these new systems. 
Then, in Section IV we will present some techniques that 
we are addressing, which may lead towards a Silver Bullet. 

A. Challenges of Future NASA Missions 

Future NASA missions will exploit new paradigms for 
space exploration, heavily focused on the (still) emerging 
technologies of autonomous and autonomic systems. Tra- 
ditional missions, reliant on one large spacecraft, are be- 
ing superceded or complemented by missions that involve 
several smaller spacecraft operating in collaboration, anal- 
ogous to swarms in nature. This offers several advantages: 


the ability to send spacecraft to explore regions of space 
where traditional craft simply would be impractical, in- 
creased spatial distribution of observations, greater redun- 
dancy, and, consequently, greater protection of assets, and 
reduced costs and risk, to name but a few. Planned mis- 
sions entail the use of several unmanned autonomous vehi- 
cles (UAV s) flying approximately one meter above the sur- 
face of Mars, covering as much of the surface of Mars in 
seconds as the now famous Mars rovers did in their entire 
time on the planet; the use of armies of tetrahedral walk- 
ers to explore the Mars and Lunar surface; constellations of 
satellites flying in formation; and the use of miniaturized 
pico-class spacecraft to explore the asteroid belt. 

These new approaches to exploration missions simulta- 
neously pose many challenges. The missions will be un- 
manned and necessarily highly autonomous. They will 
also exhibit all of the classic properties of autonomic sys- 
tems, being self-protecting, self-healing, self-configuring, 
and self-optimizing. Many of these missions will be sent to 
parts of the solar system where manned missions are simply 
not possible, and to where the round-trip delay for commu- 
nications to spacecraft exceeds 40 minutes, meaning that 
the decisions on responses to problems and undesirable sit- 
uations must be made in situ rather than from ground con- 
trol on Earth. 

Verification and Validation (V&V) for complex systems 
still poses a largely unmet challenge in the field of Comput- 
ing, yet the challenge is magnified with increasing degrees 
of system autonomy. It is an even greater open question 
as to the extent to which V&V is feasible when the system 
possesses the ability to adapt and learn, particularly in en- 
vironments that are dynamic and not specially constrained. 
Reliance on testing as the primary approach to V&V be- 
comes untenable as systems move towards higher levels 
of complexity, autonomy, and adaptability in such environ- 
ments. Swarm missions will fall into this category, and an 
early concern in the design and development of swarms will 
be the problem of predicting, or at least bounding, and con- 
trolling emergent behavior. 

The result is that formal specification techniques and for- 
mal verification will play vital roles in the future devel- 
opment of NASA space exploration missions. The role 
of formal methods will be in the specification and analy- 
sis of forthcoming missions, enabling software assurance 
and proof of correctness of the behavior of these systems, 
whether or not this behavior is emergent (as a result of com- 
posing a number of interacting entities, producing behav- 
ior that was not foreseen). Formally derived models may 
also be used as the basis for automating the generation of 
much of the code for the mission. To address the challenge 
in verifying the above missions, a NASA project, Formal 
Approaches to Swarm Technology (FAST), is investigating 
the requirements of appropriate formal methods for use in 
such missions, and is beginning to apply these techniques 
to specifying and verifying parts of a future NASA swarm- 
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based mission. 

B. ANTS: A NASA Concept Mission 

The Autonomous Nano-Technology Swarm (ANTS) 
mission will involve the launch of a swarm of autonomous 
pico-class (approximately 1kg) spacecraft that will explore 
the asteroid belt for asteroids with certain characteristics. 
Figure 2 gives an overview of the ANTS mission [47]. In 
this mission, a transport ship, launched from Earth, will 
travel to a point in space where gravitational forces on small 
objects (such as pico-class spacecraft) are all but negligi- 
ble. Objects that remain near such a point (termed a La- 
grangian point) are in a stable orbit about the Sun and will 
have a fixed geometrical relationship to the Sun-Earth sys- 
tem. From the transport ship positioned at such a point, 
1000 spacecraft that have been assembled en route from 
Earth will be launched into the asteroid belt. 

Because of their small size, each ANTS spacecraft will 
carry just one specialized instrument for collecting a spe- 
cific type of data from asteroids in the belt. As a result, 
spacecraft must cooperate and coordinate using a hierar- 
chical social behavior analogous to colonies or swarms of 
insects, with some spacecraft directing others. To imple- 
ment this mission, a heuristic approach is being consid- 
ered that provides for a social structure to the swarm based 
on the above hierarchy. Artificial intelligence technologies 
such as genetic algorithms, neural nets, fuzzy logic and on- 
board planners are being investigated to assist the mission 
to maintain a high level of autonomy. Crucial to the mission 
will be the ability to modify its operations autonomously to 
reflect the changing nature of the mission and the distance 
and low-bandwidth communications back to Earth. 

Approximately 80 percent of the spacecraft will be work- 
ers that will carry the specialized instruments (e.g., a mag- 
netometer, x-ray, gamma-ray, visible/IR, neutral mass spec- 
trometer) and will obtain specific types of data. Some will 
be coordinators (called rulers) that have rules that decide 
the types of asteroids and data the mission is interested in, 
and that will coordinate the efforts of the workers. The third 
type of spacecraft are messengers that will coordinate com- 
munication between the rulers and workers, and commu- 
nications with the Earth ground station, including requests 
for replacement spacecraft with specialized instruments as 
these are required. The swarm will form sub-swarms under 
the direction of a ruler, which contains models of the types 
of science that it wants to perform. The ruler will coordi- 
nate workers each of which uses its individual instrument to 
collect data on specific asteroids and feed this information 
back to the ruler who will determine which asteroids are 
worth examining further. If the data matches the profile of 
a type of asteroid that is of interest, an imaging spacecraft 
will be sent to the asteroid to ascertain the exact location 
and to create a rough model to be used by other spacecraft 
for maneuvering around the asteroid. Other teams of space- 
craft will then coordinate to finish the mapping of the aster- 



Fig. 2. NASA’s Autonomous Nano Technology Swarm (ANTS) mission 
scenario. 


oid to form a complete model. 

C. Problematic Issues 
C.l Size and Complexity 

While the use of a swarm of miniature spacecraft is es- 
sential for the success of ANTS, it simultaneously poses 
several problems in terms of adding significantly to the # 
complexity of the mission. 

The mission will launch 1000 pico-class spacecraft, 
many of which possibly will be destroyed by collisions 
with asteroids, since the craft, having no means of maneu- 
vering other than solar sails, will be very limited in their 
collision-avoidance capabilities. The several hundred sur- 
viving spacecraft must be organized into effective groups 
that will collect science data and make decisions as to which 
asteroids warrant further investigation. These surviving 
spacecraft effectively form a wireless sensor network [24] 
tens of millions of miles from Earth. The overhead for com- 
munications is clearly significant. 

To keep the spacecraft small, each craft only carries a sin- 
gle instrument. That is why several craft must coordinate to 
investigate particular asteroids and collect different types of 
science data. Again, while miniaturization is important, the 
use of such a scheme has a major drawback: we have no a 
priori knowledge as to which instruments will be lost dur- 
ing normal operations (where we expect to regularly lose 
craft due to collisions). 

The need to identify lost capabilities and instruments, 
and then replace them, presents an extremely complex 
problem. In the case of lost messengers and rulers, other 
craft may be promoted to replace them. It is merely the soft- 
ware that differentiates messengers and rulers from other 
workers, so mobile code serves to overcome this problem. 
When an instrument is lost, however, we have a rather dif- 
ferent problem. A worker with a damaged instrument can 
be reserved for use as a ruler, and another spacecraft with 
an identical instrument can replace it. 

An alternative would be add more features (instruments) 
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into each spacecraft, but this would increase both their size 
(a problem in such a constrained environment) and their 
power requirements. The addition of features, of course, 
also increases complexity, as identified by Lawson [32]. 

C.2 Emergent Behavior 

In swarm-based systems, interacting agents (often ho- 
mogeneous or near homogeneous agents) are developed to 
take advantage of their emergent behavior. Each of the 
agents is given certain parameters that it tries to maximize. 
Bonabeau et al. [5], who studied self-organization in so- 
cial insects, state that “complex collective behaviors may 
emerge from interactions among individuals that exhibit 
simple behaviors” and describe emergent behavior as “a set 
of dynamical mechanisms whereby structures appear at the 
global level of a system from interactions among its lower- 
level components.” 

Intelligent swarms [4] use swarms of simple intelligent 
agents. Swanns have no central controller: they are self- 
organizing based on the emergent behaviors of the simple 
interactions. There is no external force directing their be- 
havior and no one agent has a global view of the intended 
macroscopic behavior. Though current NASA swarm mis- 
sions differ from true swarms as described above, they do 
have many of the same attributes and may exhibit emergent 
behavior. In addition, there are a number of US govern- 
ment projects that are looking at true swarms to accomplish 
complex missions. 

C.3 Autonomy 

Autonomous operation is essential for the success of the 
ANTS mission concept. 

Round trip communications delays of up to 40 min- 
utes, and limited bandwidth on communications with Earth, 
mean that effective control from the ground station is im- 
possible. Ground controllers would not be able to react suf- 
ficiently quickly during encounters with asteroids to avoid 
collisions with asteroids and even other ANTS spacecraft. 
Moreover, the delay in sending instructions to the space- 
craft would be so great that situations would likely have 
changed dramatically by the time the instructions were re- 
ceived. 

But autonomy implies absence of centralized control. In- 
dividual ANTS spacecraft will operate autonomously as 
part of a subgroup under the direction of that subgroup’s 
ruler. That ruler will itself autonomously make decisions 
regarding asteroids of interest, and formulate plans for con- 
tinuing the mission of collecting science data. The success 
of the mission is predicated on the validity of the plans gen- 
erated by the rulers, and requires that the rulers generate 
sensible plans that will collect valid science data, and then 
make valid informed decisions. 

That autonomy is possible is not in doubt. What is in 
doubt is that autonomous systems can be relied upon to 


operate correctly, in particular in the absence of a full and 
complete specification of what is required of the system. 

C.4 Testing and Verification 

As can be seen from the brief exposition above, ANTS is 
a highly complex system that poses many significant chal- 
lenges. Not least amongst these are the complex interac- 
tions between heterogeneous components, the need for con- 
tinuous re-planning, re-configuration, and re-optimization, 
the need for autonomous operation without intervention 
from Earth, and the need for assurance of the correct op- 
eration of the mission. 

As mission software becomes increasingly more com- 
plex, it also becomes more difficult to test and find errors. 
Race conditions in these systems can rarely be found by in- 
putting sample data and checking whether the results are 
correct. These types of errors are time-based and only oc- 
cur when processes send or receive data at particular times, 
or in a particular sequence, or after learning occurs. To find 
these errors, the software processes involved have to be ex- 
ecuted in all possible combinations of states (state space) 
that the processes could collectively be in. Because the 
state space is exponential (and sometimes factorial) to the 
number of states, it becomes untestable with a relatively 
small number of processes. Traditionally, to get around the 
state explosion problem, testers have artificially reduced the 
number of states of the system and approximated the under- 
lying software using models. 

One of the most challenging aspects of using swarms is 
how to verify that the emergent behavior of such systems 
will be proper and that no undesirable behaviors will occur. 
In addition to emergent behavior in swarms, there are also a 
large number of concurrent interactions between the agents 
that make up the swarms. These interactions can also con- 
tain errors, such as race conditions, that are very difficult to 
ascertain until they occur. Once they do occur, it can also 
be very difficult to recreate the errors since they are usually 
data and time dependent. 

As part of the FAST project, NASA is investigating the 
use of formal methods and formal techniques for verifica- 
tion and validation of these classes of mission, and is begin- 
ning to apply these techniques to specifying and verifying 
parts of the ANTS concept mission. The role of formal 
methods will be in the specification and analysis of forth- 
coming missions, while offering the ability to perform soft- 
ware assurance and proof of correctness of the behavior of 
the swarm, whether this behavior is emergent or not. 

IV. Some Potentially Useful Techniques 
A. Autonomicity 

Autonomy may be considered as bestowing the prop- 
erties of self-governance and self-direction, i.e., control 
over one’s goals [27], [16], [43], Autonomicity is hav- 
ing the ability to self-manage through properties such as 
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self-configuring, self-healing, self-optimizing, and self- 
protecting. These are achieved through other self-properties 
such as self-awareness (including environment awareness), 
self-monitoring, and self-adjusting [45]. 

Increasingly, self-management is seen as the only viable 
way forward to cope with the ever increasing complexity of 
systems. From one perspective, self-management may be 
considered a specialism of self-governance, i.e., autonomy 
where the goals/tasks are specific to management roles [46]. 
Yet from the wider context, an autonomic element (AE), 
consisting of an autonomic manager and managed compo- 
nent, may still have its own specific goals, but also the addi- 
tional responsibility of management tasks particular to the 
wider system environment. 

It is envisaged that in an autonomic environment the AEs 
communicate to ensure a managed environment that is reli- 
able and fault tolerant and meets high level specified poli- 
cies (where a policy consists of a set of behavioral con- 
straints or preferences that influences the decisions made 
by an autonomic manager [11]) with an overarching vi- 
sion of system-wide policy-based self-management. This 
may result in AEs monitoring or watching out for other 
AEs. In terms of autonomy and the concern of undesir- 
able emergent behavior, an environment that dynamically 
and continuously monitors can assist in detecting race con- 
ditions and reconfiguring to avoid damage (self-protecting, 
self-healing, self-configuring, etc.). As such, autonomicity 
becoming mainstream in the industry can only assist in im- 
proving techniques, tools, and processes for autonomy [44]. 

B. Hybrid Formal Methods 

The majority of formal notations currently available were 
developed in the 1970s and 1980s and reflect the types of 
distributed systems being developed at that time. Current 
distributed systems are evolving and may not be able to 
be specified in the same way that past systems have been 
developed. Because of this, it appears that many people 
are combining formal methods into integrated approaches 
to address some of the new features of distributed systems 
(e.g., mobile agents, swarms, and emergent behavior). 

Integrated approaches have been very popular in speci- 
fying concurrent and agent-based systems. Integrated ap- 
proaches often combine a process algebra or logic-based 
approach with a model-based approach. The process alge- 
bra or logic-based approach allows for easy specification of 
concurrent systems, while the model-based approach pro- 
vides strength in specifying the algorithmic part of a sys- 
tem. 

Some recent hybrid approaches include: 

• CSP-OZ, a combination of CSP and Object-Z [12] 

• Object-Z and Statecharts [9] 

• Timed Communicating Object Z [14] 

• Temporal B [6] 

• Temporal Petri Nets (Temporal Logic and Petri 
Nets) [2] 


• ZCCS, a combination of Z and CCS [15] 

These and new hybrid formal methods are being inves- 
tigated to address swarm and other complex NASA mis- 
sions [41]. 

C. Automatic Programming 

For many years, automatic programming has referred, 
primarily, to the use of very high-level languages to de- 
scribe solutions to problems, which could then be trans- 
lated down and expressed as code in more traditional (lower 
level) programming languages. Pamas [36] implies that the 
term is glamorous, rather than having any real meaning, 
precisely because it is the solution that is being specified 
rather than the problem that must be solved. Brooks [8] 
supports this view, and equally criticizes the field of visual 
programming, arguing that it will never produce anything 
of value. 

Writing just five years after Brooks, Harel [20] disagrees, 
faulting Brooks for failing to recognize advances in visual 
formalisms. Now, writing almost two decades after Brooks, 
we argue that automatic code generation is not only a viable 
option, it is essential to the development of the classes of 
complex system we are discussing here, and as exemplified 
by ANTS. 

Autonomous and autonomic systems, exhibiting com- 
plex emergent behavior, cannot, in general, be fully speci- 
fied at the outset. The roles and behaviors of the system will 
vary greatly over time. While we may try to write specifica- 
tions that constrain the system, it is clear that not all behav- 
ior can be specified in advance. Consequently, the classes 
of system we are discussing will often require that code is 
generated, or modified, during execution. As a result, the 
classes of system we are describing here will require auto- 
matic code generation. 

Several tools already exist that successfully generate 
code from a given model. Unfortunately, many of these 
tools have been shown to generate code, portions of which 
are never executed, or portions of which cannot be justified 
from either the requirements or the model. Moreover, exist- 
ing tools do not and cannot overcome the fundamental in- 
adequacy of all currently available automated development 
approaches, which is that they include no means to estab- 
lish a provable equivalence between the requirements stated 
at the outset and either the model or the code they generate. 

Traditional approaches to automatic code generation, in- 
cluding those embodied in commercial products such as 
Matlab [35], in system development toolsets such as the 
B-Toolkit [31] or the VDM++ toolkit [29], or in academic 
research projects, presuppose the existence of an explicit 
(formal) model of reality that can be used as the basis for 
subsequent code generation. While such an approach is rea- 
sonable, the advantages and disadvantages of the various 
modeling approaches used in computing are well known 
and certain models can serve well to highlight certain is- 
sues while suppressing other less relevant details [37]. It 
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is clear that the converse is also true. Certain models of 
reality, while successfully detailing many of the issues of 
interest to developers, can fail to capture some important 
issues, or perhaps even the most important issues. 

That is why, we believe, future approaches to automatic 
code generation must be based on Formal Requirements- 
Based Programming [39], 

D. Formal Requirements Based Programming 

Requirements-Based Programming refers to the develop- 
ment of complex software (and other) systems, where each 
stage, of the development is fully traceable back to the re- 
quirements given at the outset. In essence, Requirements- 
Based Programming takes Model-Based Development and 
adds a front end [40]. 

The difference is that Model-Based Development holds 
that emphasis should be placed on building a model of 
the system with such high quality that automatic code 
generation is viable. While this has worked well, and 
made automatic code generation feasible, there is still the 
large analysis-specification gap that remains unaddressed. 
Requirements-Based Programming addresses that issue and 
ensures that there is a direct mapping from requirements to 
design, and that this design (model) may then be used as 
the basis for automatic code generation. 

There have been calls for the community to address 
Requirements-Based Programming, as it offers perhaps the 
most promising approach to achieving correct systems [21]. 
Although the use of Requirements-Based Programming 
does not specifically presuppose the existence of an under- 
lying formalism, the realization that proof of correctness 
is not possible without formalism [3] certainly implies that 
Requirements-Based Programming should be formal. 

In fact, Formal Requirements-Based Programming, cou- 
pled with a graphical representation for system require- 
ments (e.g., UML use cases) possesses the features and ad- 
vantages of a visual formalism described by Harel [19]. 

D.l R2D2C 

R2D2C, or Requirements-to-Design-to-Code [23], [39], 
is a NASA patent-pending approach to Requirements- 
Based Programming. 

In R2D2C, engineers (or others) may write specifications 
as scenarios in constrained (domain-specific) natural lan- 
guage, or in a range of other notations (including UML use 
cases). These will be used to derive a formal model (Fig- 
ure 3) that is guaranteed to be equivalent to the require- 
ments stated at the outset, and which will subsequently be 
used as a basis for code generation. The formal model can 
be expressed using a variety of formal methods. Currently 
we are using CSP, Hoare’s language of Communicating Se- 
quential Processes [25], [26], which is suitable for various 
types of analysis and investigation, and as the basis for fully 
formal implementations as well as for use in automated test 
case generation, etc. 



Fig. 3. The R2D2C approach, generating a formal model from require- 
ments and producing code from the formal model, with automatic re- 
verse engineering. 


R2D2C is unique in that it allows for full formal develop- 
ment from the outset, and maintains mathematical sound- 
ness through all phases of the development process, from 
requirements through to automatic code generation. The 
approach may also be used for reverse engineering, that is, 
in retrieving models and formal specifications from exist- 
ing code, as shown in Figure 3. The approach can also be 
used to “paraphrase” (in natural language, etc.) formal de- 
scriptions of existing systems. In addition, the approach 
is not limited to generating high-level code. It may also 
be used to generate business processes and procedures, and 
we have been experimenting with using it to generate in- 
structions for robotic devices that were to be used on the 
Hubble Robotic Servicing Mission (HRSM), which, at the 
time of writing, has not received a final go-ahead. We are 
also experimenting with using it as a basis for an expert sys- 
tem verification tool, and as a means of capturing domain 
knowledge for expert systems. 

D.2 R2D2C Technical Approach 

The R2D2C approach involves a number of phases, 
which are reflected in the system architecture described in 
Figure 4. The following describes each of these phases. 

D1 Scenarios Capture: Engineers, end users, and others 
write scenarios describing intended system operation. The 
input scenarios may be represented in a constrained natural 
language using a syntax-directed editor, or may be repre- 
sented in other textual or graphical forms. 

D2 Traces Generation: Traces and sequences of atomic 
events are derived from the scenarios defined in phase Dl. 
D3 Model Inference: A formal model, or formal specifi- 
cation, expressed in CSP is inferred by an automatic theo- 
rem prover — in this case, ACL2 [30] — using the traces 
derived in phase D2. A deep 1 embedding of the laws of 
concurrency [22] in the theorem prover gives it sufficient 
knowledge of concurrency and of CSP to perform the infer- 
ence. The embedding will be the topic of a future paper. 

D4 Analysis: Based on the formal model, various analyses 
can be performed, using currently available commercial or 
public domain tools, and specialized tools that are planned 
for development. Because of the nature of CSP, the model 
may be analyzed at different levels of abstraction using a 

1 “Deep” in the sense that the embedding is semantic rather than merely 
syntactic. 
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variety of possible implementation environments. This will 
be the subject of a future paper. 

D5 Code Generation: The techniques of automatic code 
generation from a suitable model are reasonably well un- 
derstood. The present modeling approach is suitable for the 
application of existing code generation techniques, whether 
using a tool specifically developed for the purpose, or ex- 
isting tools such as FDR [13], or converting to other nota- 
tions suitable for code generation (e.g., converting CSP to 
B [10]) and then using the code generating capabilities of 
the B Toolkit. 

D. 3 Advantages of the R2D2C Approach 

We have not yet had an opportunity to apply R2D2C to 
ANTS, although that is certainly our plan. 

In addition to applying it to the HRSM procedures [39], 
we have applied R2D2C to LOGOS, a NASA prototype 
Lights-Out Ground Operating System, that exhibits both 
autonomous and autonomic properties [48], [49]. We illus- 
trate the use of a prototype tool to apply R2D2C to LOGOS 
in [40], and describe our success with the approach. 

Here, we summarize some benefits of using R2D2C, and 
hence of using Formal Requirements-Based Programming 
in system development. It is our contention that R2D2C, 
and other approaches that similarly provide mathematical 
soundness throughout the development lifecycle, will: 

• Dramatically increase assurance of system success 
by ensuring 

- completeness and consistency of requirements 

- that implementations are true to the require- 
ments 

- that automatically coded systems are bug-free; 
and that 

- that implementation behavior is as expected 

• Decrease costs and schedule impacts of ultra-high de- 
pendability systems through automated development 

• Decrease re-engineering costs and delays 

E. Tool Support 

John Rushby [42] argues that tools are not the most im- 
portant thing about formal methods, they are the only im- 
portant thing about formal methods. Although we can sym- 
pathize, we do not support such an extreme viewpoint. For- 
mal methods would not be practical without suitable repre- 
sentation notations, proof systems (whether automated and 
supported by tools, or not), a user community, and evidence 
of successful application. 

We do agree, however, that tool support is vital, and not 
just for formal methods. Structured design methods took 
off when they were standardized, in the guise of UML. But 
it is only with the advent of tool support for UML that they 
became popular. The situation is analogous to high-level 
programming languages: while the community was well 
convinced of their benefits, it was only with the availability 
of commercial compilers that they became widely used. 


Tools are emerging for the development of complex 
agent-based systems such as Java-based Aglets and tools 
for autonomic systems. For automatic code generation and 
Formal Requirements-Based Programming to be practical, 
the development community will need commercial-quality 
tools. 

V. Conclusion 

The computing industry thrives on the assumption in the 
marketplace that software is reliable and correct, but many 
examples from experience over the decades cast doubt on 
the validity of this assumption. There is no automated, gen- 
eral purpose method for building correct systems that fully 
meet all customer requirements. This represents a major 
gap that has yet to be fully addressed by the software en- 
gineering community. Requirements-based programming 
has been described along with new automated techniques 
recently devised at NASA for ensuring correctness of the 
system model with respect to the requirements, as a possi- 
ble way to close this gap. 

In future mission concepts that involve advanced archi- 
tectures and capabilities — such as swarm missions whose 
individual elements not only can learn from experience but 
also must pursue science goals cooperatively — NASA 
faces system development challenges that cannot be met 
with techniques currently available in the computing indus- 
try. The challenges boil down to building reliability and 
correctness into mission systems, where complexity, au- 
tonomous operation, machine adaptation, dangerous envi- 
ronments, and remoteness combine to push such missions 
far into uncharted territory in systems engineering. With 
approaches such as autonomic computing and automated 
requirements-based programming, NASA will have greater 
possibilities for achieving success with these advanced mis- 
sion concepts. 
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